Fix stale hover reuse for unchanged regions by betamaxbandit · Pull Request #1533 · eclipse-lsp4e/lsp4e

betamaxbandit · 2026-05-13T12:50:21Z

LSPTextHover reused a completed hover request when the viewer and hover region were unchanged. As a result, a repeated hover over the same region could return stale content and avoid issuing a fresh textDocument/hover request.

Fixes #1514

rubenporras · 2026-05-14T06:00:49Z

What are the new conditions to avoid reusing a previoulsy computed hover request? Is it now always recomputed? Could you specify if as part of the commit / PR message?

LSPTextHover reused a completed hover request when the viewer and hover region were unchanged. As a result, a repeated hover over the same region could return stale content and avoid issuing a fresh textDocument/hover request. A previous request is still reused while it is in progress for the same viewer/region, but any completed requests are now treated as stale, so a subsequent hover on the same region starts a fresh textDocument/hover request instead of reusing the old completed result indefinitely. Fixes eclipse-lsp4e#1514

betamaxbandit · 2026-05-14T09:42:15Z

What are the new conditions to avoid reusing a previoulsy computed hover request? Is it now always recomputed? Could you specify if as part of the commit / PR message?

Hi, good question. No it is not always recomputed.
The previous hover request is still reused when it is still in progress and the viewer/region are unchanged. The change is specifically that a completed request is no longer reused indefinitely for the same region.

I've updated the commit message appropriately.

Cheers John

betamaxbandit · 2026-05-14T11:46:06Z

Hi @rubenporras ,

I see the following failure for my PR:

continuous-integration/jenkins/pr-merge — This commit cannot be built

I'm not sure what I need to do, if anything. Is it simply waiting for a committer to approve the run?

betamaxbandit · 2026-05-18T14:05:19Z

Hi @rubenporras ,

I see the following failure for my PR:

continuous-integration/jenkins/pr-merge — This commit cannot be built

I'm not sure what I need to do, if anything. Is it simply waiting for a committer to approve the run?

Hi @rubenporras ,
can you help me progress this please?
Cheers John

FlorianKroiss · 2026-05-18T14:31:22Z

I haven't reviewed the code (yet), but I approved the workflow runs

rubenporras · 2026-05-18T14:34:44Z

What are the new conditions to avoid reusing a previoulsy computed hover request? Is it now always recomputed? Could you specify if as part of the commit / PR message?

Hi, good question. No it is not always recomputed. The previous hover request is still reused when it is still in progress and the viewer/region are unchanged. The change is specifically that a completed request is no longer reused indefinitely for the same region.

I've updated the commit message appropriately.

Cheers John

I think this will trigger many unneeded recomputations. Could we do it so that we invalidate the last computed hover request only if the editor looses focus?

That should cover the case of external resources and be less agressive on the computation side.

betamaxbandit · 2026-05-22T17:18:18Z

What are the new conditions to avoid reusing a previoulsy computed hover request? Is it now always recomputed? Could you specify if as part of the commit / PR message?

Hi, good question. No it is not always recomputed. The previous hover request is still reused when it is still in progress and the viewer/region are unchanged. The change is specifically that a completed request is no longer reused indefinitely for the same region.
I've updated the commit message appropriately.
Cheers John

I think this will trigger many unneeded recomputations. Could we do it so that we invalidate the last computed hover request only if the editor looses focus?

That should cover the case of external resources and be less agressive on the computation side.

Hi @rubenporras ,

I like the goal of optimising the number of recomputations, and your idea of triggering this on editor focus lost, but I'm skeptical whether its worth it or always beneficial.

For instance, consider the case where the editor focus is not lost, but an external event causes the need for a recomputation. That could happen if the user starts a project build using a keybaord shortcut (ctrl+B) and this causes header files to be built which generate new values in the external resources.

Also I did some tests in vscode and see that it always generates a hover request without trying to optimise the request - see below.

Would you be willing to reconsider this please?

==
In vscode*, hovering testA twice, genrates 2 identical sets of clangd hover requests.

testA hover 1

V[17:20:34.014] <<< {"id":"clangd-proxy/internal/51","jsonrpc":"2.0","method":"textDocument/definition","params":{"position":{"character":10,"line":3},"textDocument":{"uri":"file:///c%3A/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}}

I[17:20:34.014] <-- textDocument/definition("clangd-proxy/internal/51")
V[17:20:34.014] ASTWorker running Definitions on version 1 of c:\Users\a5107948\git\CrossProbe_Williamb\717595E8-4B06-45AC-BA88-3AA846007E1C\src\test.c
I[17:20:34.014] --> reply:textDocument/definition("clangd-proxy/internal/51") 0 ms
V[17:20:34.014] >>> {"id":"clangd-proxy/internal/51","jsonrpc":"2.0","result":[{"range":{"end":{"character":13,"line":3},"start":{"character":8,"line":3}},"uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}]}

I[17:20:34.014] --> textDocument/clangd.fileStatus
V[17:20:34.014] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}

V[17:20:34.015] <<< {"id":196,"jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":10,"line":3},"textDocument":{"uri":"file:///c%3A/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}}

I[17:20:34.015] <-- textDocument/hover(196)
V[17:20:34.015] ASTWorker running Hover on version 1 of c:\Users\a5107948\git\CrossProbe_Williamb\717595E8-4B06-45AC-BA88-3AA846007E1C\src\test.c
I[17:20:34.017] --> reply:textDocument/hover(196) 1 ms
V[17:20:34.017] >>> {"id":196,"jsonrpc":"2.0","result":{"contents":{"kind":"markdown","value":"### variable `testA`  \n\n---\nType: `int`  \nValue = `100 (0x64)`  \n\n---\n```cpp\n// In test\nint testA = _A_\n```"},"range":{"end":{"character":13,"line":3},"start":{"character":8,"line":3}}}}

I[17:20:34.017] --> textDocument/clangd.fileStatus
V[17:20:34.017] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}

testA hover 2

V[17:23:52.854] <<< {"id":"clangd-proxy/internal/52","jsonrpc":"2.0","method":"textDocument/definition","params":{"position":{"character":10,"line":3},"textDocument":{"uri":"file:///c%3A/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}}

I[17:23:52.854] <-- textDocument/definition("clangd-proxy/internal/52")
V[17:23:52.856] ASTWorker running Definitions on version 1 of c:\Users\a5107948\git\CrossProbe_Williamb\717595E8-4B06-45AC-BA88-3AA846007E1C\src\test.c
I[17:23:52.856] --> reply:textDocument/definition("clangd-proxy/internal/52") 2 ms
V[17:23:52.856] >>> {"id":"clangd-proxy/internal/52","jsonrpc":"2.0","result":[{"range":{"end":{"character":13,"line":3},"start":{"character":8,"line":3}},"uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}]}

I[17:23:52.856] --> textDocument/clangd.fileStatus
V[17:23:52.856] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}

V[17:23:52.857] <<< {"id":197,"jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":10,"line":3},"textDocument":{"uri":"file:///c%3A/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}}

I[17:23:52.857] <-- textDocument/hover(197)
V[17:23:52.857] ASTWorker running Hover on version 1 of c:\Users\a5107948\git\CrossProbe_Williamb\717595E8-4B06-45AC-BA88-3AA846007E1C\src\test.c
I[17:23:52.859] --> reply:textDocument/hover(197) 2 ms
V[17:23:52.859] >>> {"id":197,"jsonrpc":"2.0","result":{"contents":{"kind":"markdown","value":"### variable `testA`  \n\n---\nType: `int`  \nValue = `100 (0x64)`  \n\n---\n```cpp\n// In test\nint testA = _A_\n```"},"range":{"end":{"character":13,"line":3},"start":{"character":8,"line":3}}}}

I[17:23:52.860] --> textDocument/clangd.fileStatus
V[17:23:52.860] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///c:/Users/a5107948/git/CrossProbe_Williamb/717595E8-4B06-45AC-BA88-3AA846007E1C/src/test.c"}}

*: vscode using extension "llvm-vs-code-extensions.vscode-clangd" and settings.json set with:
"clangd.arguments": [
"--log=verbose"

betamaxbandit mentioned this pull request May 13, 2026

LSPTextHover reuses completed hover result for unchanged region and does not issue a new textDocument/hover request #1514

Open

betamaxbandit force-pushed the fix1514 branch from 925c01b to f2e0895 Compare May 13, 2026 16:10

betamaxbandit force-pushed the fix1514 branch from f2e0895 to b52d4ec Compare May 14, 2026 09:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix stale hover reuse for unchanged regions#1533

Fix stale hover reuse for unchanged regions#1533
betamaxbandit wants to merge 1 commit into
eclipse-lsp4e:mainfrom
betamaxbandit:fix1514

betamaxbandit commented May 13, 2026

Uh oh!

rubenporras commented May 14, 2026

Uh oh!

betamaxbandit commented May 14, 2026

Uh oh!

betamaxbandit commented May 14, 2026

Uh oh!

betamaxbandit commented May 18, 2026

Uh oh!

FlorianKroiss commented May 18, 2026

Uh oh!

rubenporras commented May 18, 2026

Uh oh!

betamaxbandit commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

betamaxbandit commented May 13, 2026

Uh oh!

rubenporras commented May 14, 2026

Uh oh!

betamaxbandit commented May 14, 2026

Uh oh!

betamaxbandit commented May 14, 2026

Uh oh!

betamaxbandit commented May 18, 2026

Uh oh!

FlorianKroiss commented May 18, 2026

Uh oh!

rubenporras commented May 18, 2026

Uh oh!

betamaxbandit commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants